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(57) Abstract 



A method and apparatus are disclosed for scheduling control inputs in an embedded real-time system through anonymous events. 
An object-oriented design pattern is provided that treats all events anonymously using an abstracted interface. Events are said to be 
anonymous since the details of each event are irrelevant, i.e., only the resource usage of the event is characterized and exposed. Deadlines 
and priorities are assigned to each event, as appropriate for the required quality of service (i.e., urgent events, routine events or deferred 
events). Response times for each event are appropriate to the quality of service associated with the event. Guaranteed response time 
determinism for time-critical events is implemented by re-clocking the event to a periodic time indication, such as a video synchronization 
signal delineating frames in a video feed. Events are validated against system resources at the time the events are submitted to the system to 
ensure that sufficient resources will exist when the event is to be executed, and if sufficient resources will exist, a commitment is provided. 



BNSDOCID: <WO 0063776A2 I > 



FOR THE PURPOSES OF INFORMATION ONLY 
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL Albania 

AM Armenia 

AT Austria 

AU Australia 

AZ Azerbaijan 

BA Bosnia and Herzegovina 

BB Barbados 

BE Belgium 

BF Burkina Faso 

BG Bulgaria 

BJ Benin 

BR Brazil 

BV Belarus 

CA Canada 

CF Central African Republic 

CG Congo 

CH Switzerland 

CI Cdte d'lvoire 

CM Cameroon 

CN China 

CU Cuba 

CZ Czech Republic 

DE Germany 

DK Denmark 

EE Estonia 



ES 


Spain 


LS 


Lesotho 


FI 


Finland 


LT 


Lithuania 


FR 


France 


LU 


Luxembourg 


GA 


Gabon 


LV 


Latvia 


GB 


United Kingdom 


MC 


Monaco 


GE 


Georgia 


MD 


Republic of Moldova 


GH 


Ghana 


MG 


Madagascar 


GN 


Guinea 


MK 


The former Yugoslav 


GR 


Greece 




Republic of Macedonia 


HU 


Hungary 


ML 


Mali 


IE 


Ireland 


MN 


Mongolia 


IL 


Israel 


MR 


Mauritania 


IS 


Iceland 


MW 


Malawi 


IT 


Italy 


MX 


Mexico 


JP 


Japan 


NE 


Niger 


KE 


Kenya 


NL 


Netherlands 


KG 


Kyrgyzstan 


NO 


Norway 


KP 


Democratic People's 


NZ 


New Zealand 




Republic of Korea 


PL 


Poland 


KR 


Republic of Korea 


PT 


Portugal 


KZ 


Kazakstan 


RO 


Romania 


LC 


Saint Lucia 


RU 


Russian Federation 


LI 


Liechtenstein 


SD 


Sudan 


LK 


Sri Lanka 


SE 


Sweden 


LR 


Liberia 


SG 


Singapore 



SI 


Slovenia 


SK 


Slovakia 


SN 


Senegal 


SZ 


Swaziland 


TD 


Chad 


TG 


Togo 


TJ 


Tajikistan 


TM 


Turkmenistan 


TR 


Turkey 


TT 


Trinidad and Tobago 


UA 


Ukraine 


UG 


Uganda 


US 


United States of America 


uz 


Uzbekistan 


VN 


Viet Nam 


vu 


Yugoslavia 


zw 


Zimbabwe 



BNSOOCID- <WO _0063776A2_I_> 



WO 00/63776 PCT/EPOO/03043 

1 

0]bject-Qriented system having anonymous scheduler design pattern. 



CROSS REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of United States Provisional Application 
Number 60/129,300, filed April 15, 1999. 

5 FIELD OF THE INVENTION 

The present invention relates to object-oriented programming techniques, and 
more particularly, to a method and apparatus for scheduling control input in an embedded 
real-time system using anonymous events. 

10 BACKGROUND OF THE INVENTION 

Object-oriented design is a design discipline that promotes good software 
design by providing tools that make it easy to create modules that are independent of one 
another. Dependencies between modules are minimized through the creation of interfaces 
that do not depend on specific implementations. Each object within an object-oriented system 

1 5 is defined by an interface and an implementation. Software clients' external to the object 
depend completely on the object interface, and not the details of the object implementation. 
The implementation of an object contains the mechanisms and detail necessary to carry out 
the behavior of the object. 

Object-oriented programs are collections of objects that relate to one another 

20 through these abstract interfaces. For a more detailed discussion of object-oriented designs, 
see, for example, Booch, Grady, Object-Oriented Analysis and Design with Applications 
(Benjamin Cummings, 1994); Martin, Robert C, Designing Object-Oriented C++ 
Applications Using the Booch Method, (Prentice Hall, 1995); Jacobson, Ivar, Object- 
Oriented Software Engineering, (Addison Wesley, 1992) or Rumbaugh, et. al., Object- 

25 Oriented Modeling and Design, (Prentice Hall, 1991), each incorporated by reference herein. 

The collections of objects are themselves the subject of organization into 
modules that have a defined interface and embody some aspect of overall system behavior. 
Useful organizational patterns of these object collections have emerged as reusable solutions 
to specific problems in object-oriented design. Recognizing these common collaborations 
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among objects can lead to the development of a system architecture that is smaller, simpler, ■ 
and more understandable. These design patterns capture the structure of solutions that occur 
repeatedly in a particular design context. 

Object-oriented patterns related to this invention include (i) the Command 
5 pattern described in Gamma, et. al., Design Patterns Elements of Reusable Object-Oriented 
Software, (Addison Wesley, 1994); (ii) the Pedestal and Reactor patterns described in 
Coplien & Schmidt, Editors. Pattern Languages of Program Design 1, (Addison Wesley, 
1995); (iii) the Command Processor and Half Sync/Half Sync patterns described in Vlissides 
& Coplien & Kerth, Editors, Pattern Languages of Program Design 2, (Addison Wesley, 
10 1996), and (iv) the Recursive Control pattern described in Martin & Riehle & Bushman, 
Editors, Pattern Languages of Program Design 3, (Addison Wesley, 1998). The discussions 
of each of these object-oriented patterns are incorporated by reference herein. 

Object-oriented designs and design patterns are also applicable to real-time 
embedded systems. An embedded system is a computing solution developed for a specific 
1 5 real-world application, usually as a control mechanism for electronic equipment or devices. 
The term "real-time" implies that these systems have temporal requirements. Such systems 
are developed to satisfy the following three primary criteria: guaranteed timing deadlines, 
predictable response times, and stability in overload. A real-time system is said to be 
deterministic if it can guarantee the response time to control events. For a more detailed 
20 discussion of real-time design issues, see, for example, Klein et. al., A Practitioner's 
Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-time 
Systems, (Kluwer Academic Publishing, 1993), incorporated by reference herein. 

Even within the possibilities granted by the above-described object-oriented 
designs and design patterns, it is still a common practice in embedded real-time systems to 
25 custom design an object model for each new set of requirements. Despite the apparent 

advantages, the reuse of object components in practice is minimal. This is due, in part, to the 
temptation of designers to treat each design uniquely. On the most basic level, most 
embedded real-time designs share a remarkably common set of requirements. Specifically, 
the system accepts a control input, processes the control input according to some established 
30 criteria (or control policy), and issues a set of commands to its associated hardware (through 
the hardware access layer, or drivers). While the control policy of a system and its hardware 
access layer may be arguably unique, the control input does not have to be. 

There are three distinct quality of service (QoS) levels required in most multi- 
purpose embedded real-time systems. A quality of service is a means to classify response 
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timfes for Events. Automation of a system usually involves a control interface to an external 
computer. By necessity, this interface must guarantee a consistent and predictable level of 
performance and provide fast response times to meet the expectations given a machine-to- 
machine interface. Closely related to immediate automation commands is the desire to 
5 schedule events for execution at a specific time in the future. Such ability would be desirable, 
for example, if the event were either bound to an exact time, or multiple system components 
needed to execute events synchronously in order to conduct a facility-wide event. 

These deferred events (i.e., events scheduled for execution at a specific future 
time) are usually issued through an automation interface, but stamped with a specific 

10 execution time. Although the use of automation to control embedded systems continues to 
increase, direct manual control will always be required. The quality of service demands of a 
human interface, however, differ significantly from the expectations of an automation 
interface. Where it is reasonable to expect the fastest response times from a machine, humans 
do not have such instant needs. Instead, response times must only be sufficient to give the 

1 5 human operator a perception of connection with the system by meeting human sensory 
perception deadlines. 

Current systems rarely make distinctions for events based on these different 
levels of quality of service, opting instead for the simplicity of handling all events in the 

^ same way. This leads to several problems. When higher priority automation events are held 

20 off, waiting for system resources behind lower-priority manual events, a priority inversion 

occurs. Deferred events, when supported at all, are usually held in a container (or queue) until 
their execution time arrives, and then must contend for resources with other events at that 
time. Since there are no guarantees that system resources will be sufficient at the execution 
time for a given event, a delayed validation may occur. A delayed validation occurs when the 

25 system accepts an event for processing at a later time, but the event fails due to conditions 
present at the scheduled run-time. 

Moreover, deterministic (guaranteed and predictable) response times, critical 
to the requirements of an automation interface, are usually handled by processing events as 
"fast as possible." The resulting worst-case performance is measured and automation events 

30 are specified with a hold-off time. Each new revision of the software must then be measured 
and hold-off times renegotiated with end users. 

Currently, there is no design pattern that adequately addresses control input 
processing in current embedded systems design. Control input processing issues are usually 
tightly bound with the unique design of the control policy, making reuse impractical and 
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performance tweaking a must. Thus, the control policy of the application is burdened' with the 
responsibility of maintaining real-time design goals. 

A need therefore exists for an object-oriented design pattern that addresses the 
above-described deficiencies in the current design of embedded real-time systems. A further 
5 need exists for an object-oriented class pattern that abstracts the control input scheduling in 
an embedded real-time system using anonymous events. 

SUMMARY OF THE INVENTION 

Generally, a method and apparatus are disclosed for scheduling control inputs 
10 in an embedded real-time system through anonymous events. An object-oriented design 

pattern is provided that treats all events anonymously using an abstracted interface. As used 
herein, events are said to be anonymous since the details of each event are irrelevant, i.e., 
only the resource usage of the event is characterized and exposed. 

Deadlines and priorities are assigned to each event, as appropriate for the 
1 5 required quality of service. In an illustrative embodiment, the following three quality of 

service levels may be assigned to an event: (i) urgent (for automation events), (ii) routine (for 
manual events), or (iii) deferred (for time specific events). Response times for each event are 
appropriate to the quality of service associated with the event. 

According to one aspect of the invention, deterministic processing is 
20 implemented by re-clocking the event to a periodic time indication, such as a video 

synchronization signal (video SYNC) delineating frames in a video feed. In this manner, 
guaranteed response time determinism is achieved by synchronizing events to a common 
time indication. According to another aspect of the invention, events are validated against 
system resources at the time the events are submitted to the system to ensure that sufficient 
25 resources exist for the later time when the event is to be executed. Thereafter, the present 
invention provides a commitment based on this validation. 

A more complete understanding of the present invention, as well as further 
features and advantages of the present invention, will be obtained by reference to the 
following detailed description and drawings. 



30 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a unified modeling language (UML) sequence diagram illustrating an 
architectural view of the design pattern of the present invention; 
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FIG. 2 illustrates the timing relationship of events re-clocked to a periodic 
time indication; 

FIG. 3 illustrates a UML class diagram for the anonymous scheduler of the 
present invention; 

FIG. 4 provides a collaboration diagram showing urgent and deferred requests 
for the anonymous scheduler of the present invention; and 

FIG. 5 illustrates an urgent and routine sporadic server state diagram for 
urgent and routine directors of FIG. 3 . 

DETAILED DESCRIPTION 

FIG. 1 provides a unified modeling language (UML) sequence diagram 
illustrating an architectural view of the design pattern of the present invention. The present 
invention provides an object-oriented design pattern that addresses previous deficiencies in 
the current design of embedded real-time systems. In particular, an object-oriented class 
pattern is provided that abstracts the control input scheduling in an embedded real-time 
system through anonymous events. Thus, the present invention treats all events anonymously 
through an abstracted interface. As used herein, events are said to be anonymous since the 
details of each event are irrelevant. In other words, only the resource usage of the event is 
characterized and exposed. 

In addition, the present invention assigns deadlines and priorities to each 
event, as appropriate for the associated quality of service level demanded by the control 
source. In the illustrative embodiment, the following three quality of service levels may be 
assigned to an event: (i) urgent (for automation events), (ii) routine (for manual events), or 
(iii) deferred (for time specific events). Routine events are not expected to meet hard 
deadlines. These are typically events performed in response to manual control inputs. Urgent 
events are time-critical and deterministic, the response typically given to automation control 
commands. Deferred events are time-stamped for execution at a specific time and date. 
Response times for each event are appropriate to the quality of service associated with the 
event. All three levels of quality of service found in embedded real-time systems are 
addressed by the design, removing priority inversion issues. 

According to another aspect of the present invention, discussed further below 
in conjunction with FIG. 2, deterministic processing is implemented by re-clocking the event 
to a periodic time indication. In this manner, guaranteed response time determinism is 
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achieved by synchronizing events to a common time indication (buffering events for*a period 
of time, and then releasing the buffered events for execution at the appropriate time). 

According to yet another aspect of the invention, events are validated against 
system resources at the time the events are submitted to the system to ensure that sufficient 
5 resources exist for the later time when the event is to be executed. Thus, since the availability 
of system resources is validated at the time the events are submitted to the system, the present 
invention replaces a conventional receipt-acknowledgement protocol with a commitment 
based on this validation. This commitment is based on a validation of system resources for 
each event, even if the event occurs much later. 
10 Generally, the design pattern of the present invention adheres to the "open- 

closed" principle of object-oriented design. In other words, the architecture of the design 
pattern is open for additions (new events may be added), but closed to modification (the 
program elements of the design pattern do not need to change). 

FIG. 1 provides a unified modeling language (UML) sequence diagram that 
15 illustrates an architectural view of how a typical embedded real-time system would employ 
the design pattern of the present invention. For a discussion of the UML notations used 
herein, see, for example, UML Notation Guide, version 1.1 (Sept. 1, 1997), downloadable 
from http : / /www . omg . org/docs/ad/97-08-05 .pdf , and incorporated by 
reference herein. As shown in FIG. 1, a control boundary module 110 receives a command 
20 140 from an external control mechanism 1 05, which may be, for example, a person. 

As discussed further below in conjunction with FIG. 3, the control boundary 
1 10 is responsible for decoding the command 140 and creating an event 142 to carry out the 
required action. It is noted that additional control parameters may be bound to the event 142, 
as required by the nature of the control command. The event 142 has an associated quality of 
25 service, which may include a specific execution time in the case of a deferred event. Again, 
the event 142 is validated by the anonymous scheduler 100 against system resources at the 
time the events are submitted to the system to ensure that sufficient resources exists for the 
later time when the event is to be executed. Following this validation, the anonymous 
scheduler 100 generates a commitment or rejection 144. 
30 As previously indicated, an important element of the design pattern is the 

ability to achieve detenninistic response times to critical events, which is accomplished by 
re-clocking incoming events to an external time base. Critical events are classified as having 
an urgent quality of service. Instead of executing events as fast as possible, the event is 
delayed until the next timing tick. The timing relationship among events is shown in FIG. 2. 
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The duration of an individual timing tick, N, depends upon the needs of a given system, but is 
most likely a specific unit of time that is utilized and is available in the system. For example, 
a tick in the context of a video system would be a video frame. As shown in FIG. 2 and 
discussed further below, events are accumulated or buffered during a first time interval, N, 
5 and are thereafter released for execution at an appropriate subsequent time interval, such as 
interval N+l, prior to the corresponding deadline. 

The re-clocking technique shown in FIG. 2 provides a deterministic response 
over a strictly fixed-time response, since the event measured with respect to the time 
reference always executes in period N+l, following its acceptance in period N. A strictly 
1 0 fixed-time response may execute either in period N or N+l , since the event is always added 
asynchronously with respect to the time reference. A fixed-time response may typically 
execute in period N if it was added early in the period, or in N+l if it was added at the end of 
the period. 

Thus, returning to FIG. 1, an event may be in an event pending state 146 until 

15 the corresponding appropriate execution time. Such a wait may be incurred by an urgent 
event, buffered until the next period, or by a deferred event before its scheduled execution 
time. Once the appropriate execution time occurs, the event is released for execution, and an 
execute event message 148 is provided to the control policy 120 which handles the event in a 
predefined manner in accordance with the underlying policy. Thus, a write control message 

20 1 50 is provided to the system hardware 130, which generates a result 1 52. The control policy 
120 then provides an indication 154 of the result to the control boundary 110, which in turn 
provides a response 156 to the control mechanism 105. 

FIG. 3 illustrates the UML class diagram for the anonymous scheduler 100 of 
the present invention. As shown in FIG. 3, the anonymous scheduler 100 of the present 

25 invention includes a scheduler participant 3 1 0 that (i) provides an interface for the input 
control modules 1 10 of the system, (ii) validates events to ensure that sufficient execution 
budget and hardware capacity exist, (iii) assigns the event for execution based on an 
associated quality of service, (iv) provides a commitment to the control mechanism 105 upon 
validation, and (v) manages a timeline of deferred events. As shown in FIG. 3, the scheduler 

30 participant 310 has two private data members (immediate Agenda and deferred Timeline). In 
addition, the scheduler participant 310 provides a public (visible) method (Add) and a private 
method (SchedulerRunLoop). 

In addition, the anonymous scheduler 100 of the present invention includes an 
event participant 360 that specifies an interface for derived concrete events, and thus provides 
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an abstract means to conduct an individual control action. A concrete event is defined with a 
specific action within a control policy, the required quality of service, and the impact on 
system resources. 

As shown in FIG. 3, the event participant 360 provides four public methods (Action, 
5 Execution Cost, Portlmpact and QoS). Each concrete event derived from event 360 must be 
specified with two key indicators, execution cost and port impact, that each define the 
computing resources needed to perform the action associated with the event 360. Execution 
cost is the worst-case execution time of the action. Port impact is the degree to which the 
action consumes any control limits imposed by hardware. Control limits are usually specified 
1 0 per unit of time and are necessary to prevent overrunning the ability of the hardware to react 
to the resulting command. For example, a communications medium may be defined in terms 
of its message throughput, or an image processor may only be capable of performing an 
action once every video frame. 

An agenda participant 320 is a repository of all events that must execute at a 
1 5 specific time. The agenda participant 320 contains the total resource utilization for a specific 
moment in time. As shown in FIG. 3, the agenda participant 320 provides four private 
methods (deferred Time, executionBudget, port Budget and event Queue). A collection of 
agenda participants 320 is maintained in the data container priority Queue participant 340. 
Thus, a priority queue participant 340 is a collection of deferred agendas 320 arranged in 
20 order by execution time. 

In addition, a director participant 330 runs a collection of events 360 to be 
executed at a particular quality of service (QoS). Thus, a separate director participant 330 
might be provided for urgent events, routine events and deferred events. In the illustrative 
embodiment, the urgent director participant 330 handles both urgent and deferred events (at 
25 the appropriate time). The director participant 330 provides two public methods (Add and 
Current Budget) and a private method (Director RunLoop). The director participant 330 
maintains the running budget, Current Budget, for the remaining events 360. A queue 
participant 350 is a collection of events 360 arranged in first-in-first-out order. 

FIG. 4 provides a collaboration diagram showing urgent and deferred requests 
30 for the anonymous scheduler of the present invention. As shown in FIG. 4, the control 
boundary module 110 receives commands from an external control mechanism 105. The 
control boundary modules 1 10 are responsible for decoding the command and creating an 
event 360-n to carry out the required action. Additional control parameters may be bound to 
the event 360-n, as required by the nature of the control command. The event 360-n is also 
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set to a specific quality of service (QoS), which may include a specific execution time in the 
case of a deferred event. The quality of service is often associated with the control 
mechanism itself. The event 360 is then submitted to the scheduler 310. 

Concrete events are defined within the domain of the system control policy to 
5 carry out a specific action. Each event 360 is classified according to its quality of service 
(QoS), allowing the system to execute the event 360 with the appropriate priority. Thus, 
priority inversion, where a low priority event delays the execution of a time-critical event, is 
avoided. 

As discussed hereinafter, FIG. 4 illustrates four different processing threads. A 

10 first processing thread (1) traces the processing of the addition of a new event with a deferred 
quality of service. A second processing thread (2) traces the processing of the addition of a 
new event with an urgent quality of service. A third processing thread (3) is initiated upon a 
predefined period. A fourth processing thread (4) is initiated upon a predefined trigger. 

The first and second processing threads (1 and 2) trace the processing of the 

15 addition of a new event with a deferred or urgent quality of service, respectively. As 

previously indicated, when an event 360 is submitted to the scheduler 310, the execution time 
and port impact of the event 360 are validated to ensure a sufficient budget exists to 
accomplish the action, given its quality of service. Thus, as shown in FIG. 4, attempts to add 
an event are first processed by the scheduler 310. The total execution costs 

20 (executionBudget) for a specific deferred time index is maintained within an agenda 320. An 
immediate agenda 320-1 exists to coordinate events 360 for the next (most immediate) set of 
urgent actions to be executed. 

Events 360 are valid if there is enough capacity remaining to add the event 
360. Routine events (that are not expected to meet hard deadlines) may take many individual 

25 time units to complete, so new events 360 are compared directly against the total remaining 
items in the routine director 330. For each event 360, the scheduler 310 will identify the 
director 330 that will handle the event based on the quality of service associated with the 
event, and will then validate the execution budget accordingly. Events 360 that exceed the 
budget are deferred to a later execution time or rejected (depending on local policy). 

30 Assuming that a test 1.1 determines that sufficient execution budget is 

available, deferred events are stored in an appropriate agenda 320-n according to the 
scheduled execution time of the event 360. Likewise, assuming that a test 2.1 determines that 
sufficient execution budget is available, urgent events that are added to the scheduler 310 
over a given period of time are stored in an immediate agenda 320-1 until the next execution 
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period arrives. A message is returned to the control boundary 410 to indicate the success of 
adding the event to the schedule. 

The third processing thread (3) is initiated upon a predefined period. This 
period is synchronous with the periodic time indication illustrated in FIG. 2. Each tick 
5 denotes the start of a period. At the beginning of this period, a loop is initiated at thread 3.1 
for all accumulated events 360-n to obtain the events (3.1.1), remove the events from the 
queue (3.1.1.1) and add the events (3.1.2) to the urgent director 330 for execution at high 
priority. The scheduler 310 will trigger processing of the urgent director 330 at thread 3.2. 

The scheduler 310 also manages the deferred agenda 320 timeline. After the 

1 0 scheduler 3 1 0 has loaded the urgent director 330 with all its events for the current period, the 
scheduler 310 checks for the next deferred execution time at thread 3.3. If a time exists in the 
timeline that will be due following the next urgent period, then it is removed from the 
timeline and replaces the immediate agenda 320-1 (thread 3.3.1). In this way, the budget for 
deferred events is assured, and incoming urgent events are validated against this pre-allocated 

15 budget. Additionally, these deferred events are executed with critical timing requirements at 
the exact time they were scheduled. 

Each director 330 instance is associated with a specific quality of service, 
where urgent-deferred events are run with an urgent quality of service at high priority, as 
described above, and routine events are run with a routine quality of service at a lower 

20 priority. As shown in FIG. 4, the director 330 performs a test at thread 4 to detect a trigger of 
the next execution time. Upon detecting the trigger, a loop is initiated at thread 4.1 for each 
queued event to run the event. Thus, the event 360 is removed from the queue during thread 
4.1.1 and the appropriate action is performed during thread 4.1 .2. 

FIG. 5 illustrates an urgent and routine sporadic server state diagram 500-U 

25 and 500-R, respectively. As shown in FIG. 5, the director 330 gets events 360 from its queue, 
and calls its Action( ). Each director 330 has three states: wait, service and replenish. If no 
events are queued, the director 330 will enter the wait state 5 1 0 until the occurrence of a 
predefined event (a trigger for an urgent director and an event in the case of a routine 
director). It is noted that for an urgent director 330-u, urgent events are accumulated during 

30 one period and released for execution during the following period, as indicated by the 
"event/queue event" transition notation for wait state 510-u. It is further noted that the 
"event/queue event" transition in FIG. 5 corresponds to thread 2.1 in FIG. 4, and the trigger 
transition from wait state 510-u in FIG. 5 corresponds to the "3.2 Trigger" message in FIG. 4. 
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'« «" Once the predefined event has occurred, or if there are events queued, the 
director 330 will enter the servicing state 520 to perform the event(s) with the appropriate 
priority level. Once the event is serviced, the director 330 will enter the replenish state 530, 
and again sleep for a predefined interval. 
5 The number of actors dequeued in each run period is determined by the 

execution budget of the server. Each of these servers is designed to meet the requirements 
imposed by Rate Monotonic Analysis (RMA) to ensure they meet critical timing deadlines. 

It is to be understood that the embodiments and variations shown and 
described herein are merely illustrative of the principles of this invention and that various 
1 0 modifications may be implemented by those skilled in the art without departing from the 
scope and spirit of the invention. 
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1 . A method for interfacing to a system having at least one control input, 
comprising the steps of: 

determining at least one event (360) associated with said control input; 
defining the resource usage for each of said events (360); and 
5 - scheduling the performance of said events (360) based on said resource usage 

and a required quality of service using an object oriented class pattern. 

2. The method according to claim 1 , further comprising the step of validating 
said events (360) to ensure that sufficient resources exist for the scheduled execution time. 

10 

3 . The method according to claim 1 , further comprising the step of providing a 
commitment to perform said event (360) if sufficient resources exist to perform said event 
(360) prior to said deadline. 



1 5 4. The method according to claim 1 , further comprising the step of managing a 

timeline (200) of deferred events (360). 

5. The method according to Claim 1 , where the step of defining the resource 

usage for each of said events (360) includes establishing a deadline and priority for each of 
20 said events (360). 



6. A method for scheduling a control input, comprising the steps of: 

determining one or more asynchronous time-critical events (360) associated 
with said control input; 

25 - synchronizing said one or more events (360) to a common time reference 

(200) having a predefined period; and 

establishing a deadline for each of said events (360) that are deterministic with 
respect to said common time reference. 
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7. - ' The method of claim 6, wherein each event (360) is delayed until the start of a 
period in said time reference. 

8. The method of claim 6, further comprising the step of accumulating events 
5 (360) received in a given period in said time reference at least until the start of the next 

period. 

9. The method of claim 6, further comprising the step of releasing accumulated 
events (360) for execution at an indicated period in said time reference prior to said 

10 corresponding deadline. 

10. A method for scheduling a control input, comprising the steps of: 
determining at least one event (360) associated with said control input; 
establishing a deadline for each of said events (360) based on a required 

1 5 quality of service; 

determining if sufficient resources exist to perform said event (360) prior to 
said deadline; and 

providing a commitment to perform said event (360) if sufficient resources 
exist to perform said event (360) prior to said deadline. 

20 

1 1 . The method according to claim 1 0, further comprising the step of managing a 
timeline (200) of deferred events (360). 

12. The method according to claim 1 0, wherein said step of determining if 

25 sufficient resources exist further comprises the step of evaluating an execution budget and a 
hardware capacity. 

13. The method according to claim 10, wherein said step of determining if 
sufficient resources exist confirms the capacity to perform said event (360) prior to said 

30 deadline, given an associated quality of service. 

14. A system for interfacing to a system having at least one control input, 
comprising: 

a memory for storing computer readable code; and 
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a processor operatively coupled to said memory, said processor configured to: 
determine at least one event (360) associated with said control input; 
define the resource usage for each of said events (360); and 
schedule the performance of said events (360) based on said resource usage 
5 and a required quality of service using an object oriented class pattern. 

15. A system for scheduling a control input, comprising: 
a memory for storing computer readable code; and 

a processor operatively coupled to said memory, said processor configured to: 
1 o - determine one or more asynchronous time-critical events (360) associated with 

said control input; 

synchronize said one or more events (360) to a common time reference having 

a predefined period; and 

establish a deadline for each of said events (360) that is deterministic with 

1 5 respect to said common time reference. 

1 6. A system for scheduling a control input, comprising: 
a memory for storing computer readable code; and 

a processor operatively coupled to said memory, said processor configured to: 
20 - determine at least one event (360) associated with said control input; 

establish a deadline for each of said events (360) based on a required quality 

of service; 

determine if sufficient resources exist to perform said event (360) prior to said 

deadline; and 

25 - provide a commitment to perform said event (360) if sufficient resources exist 

to perform said event (360) prior to said deadline. 



JNSDOCID- <WO 0063776A2 I > 



WO 00/63776 



PCT/EP00/03043 




nnfi.T77BA2 I » 



WO 00/63776 



PCT/EP00/03043 



2/4 



TICK N TICK N+1 TICK N+2 
* f T 



FIG. 2 



ACCUMULATE EXECUTE 
EVENTS EVENTS 



200 



EFFECT 
DEADLINE 



100 



Scheduler 

-immediateAgenda 
-delerredTimeline 



+Add( Event* ) 
-SchedulerRunLoop() 



FIG. 3 



-310 



rO 
1 



1.: 



Agenda 

-delerredTime 
-execulionBudget 
-portBudget 
-eventQueue 



75 



Agenda ' 



PriorilyQueue 
~^340 



«type» 
Event 



+Action() 
+ExecutionCost() 
+Porllmpact() 
+Qos 



320 



^.* ^ — 330 



Director 



+Add( Event*) 
+ CurrentBudget() 
-DirectorRunLoop() 

— 7> 



Event* 



Queue 



350 



360 



BNSDOCID- <WO 0063776A2 I > 



WO 00/63776 



PCT/EP00/03043 



3/4 




Conlrol Boundary 
Module 



4 

Commit 



3. [PERIOD]: READY 



c 



-110 



1.ADD 
DEFERRED 
QoS 



2. Add 
Urgenl 
QoS 



Scheduler 



310 



3.1 *{i=1..nEVENTS] 
TRANSFER TO DIRECTOR 



2.1 [budget valid) 
Add To 
Budget 



3.3.1 Set 
Agenda 



3.1.1 
Get 
next 
event 

i 

Event* 



SCHEDULER TASK 

3.1.2 Add O-^ 



3.2 Trigger 



3.3 
[nextPeriod 
=time-1] 
Remove 

4 

Agenda* 



1.1 
[budget 



_ Add to 
T budget 
at time 



Agenda * 
320-n 



PriorityQueue 
340 



immediateAgenda: 
Agenda m 



2.1.1 Enqueue 



3.1.1.1 Dequeue 



4 

Event* 



Queue 



Event* 
360-n 

m\ 



Urgent:Director 
330 



URGENT TASK 

_4.[trigger] : Ready 

4.1*[1..nEvents|: 
RunEvent 



4.1.2 
Action 

4 



3.1.2.1 
Enqueue 

? 



4.1.1 
Dequeue 



4 

Event ' 



Event* 
360-n 



Queue 



350 



fvent 
360-n 



FIG. 4 



BNSDOCID: <WO 0063776A2 I > 



WO 00/63776 



PCT/EP00/03043 



4/4 



r 



URGENT 



TRIGGER 



c 




EVENT /QUEUE 
\ J EVENT 

510-U 

[NO EVENTS QUEUED] 



WAITING 



DO /SLEEP 




SERVICING 



DO /EXECUTE EVENTS 
AT HIGH PRIORITY 



[EVENTS QUEUED] 



PERIOD EXPIRES 



EVENT /QUEUE 
EVENT 



REPLENISHING 




[EVENTS QUEUED] A 



a 



SERVICING 



DO /EXECUTE EVENT 
AT LOW PRIORITY 



PERIOD EXPIRES 



EVENT /QUEUE 
EVENT 



520-R 



EVENT 
SERVICED 



REPLENISHING 



DO/SLEEP FOR 
REPLENISHMENT 
PERIOD 



o 

EVENT /QUEUE 
EVENT 



530-R 



500-U 



500-R 



FIG. 5 



BNSDOCID: <WO 0063776A2 I > 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(J9) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
26 October 2000 (26.10.2000) 




PCT 



III 



(10) International Publication Number 

WO 00/63776 A3 



(51) International Patent Classification 7 : G06F 9/54, 9/46 

(21) International Application Number: PCT/EPOO/03043 

(22) International Filing Date: 5 April 2000 (05.04.2000) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

60/129,300 
09/481,772 



15 April 1999 (15.04.1999) US 
1 1 January 2000 (11.01 .2000) US 



(71) Applicant: KONINKLIJKE PHILIPS ELECTRON- 
ICS N.V. [NL/NLJ: Groenewoudseweg 1, NL-5621 BA 
Eindhoven (NL). 

(72) Inventor: ISHAM, Karl; Prof. Holstlaan 6, NL-5656 AA 
Eindhoven (NL). 



(74) Agent: GROENENDAAL, Antonius, W., M.; Interna- 
tional Octrooibureau B.V., Prof. Holstlaan 6, NL-5656 
AA Eindhoven (NL). 

(81) Designated State (national): JP. 

(84) Designated States (regional): European patent (AT, BE, 
CH, CY, DE, DK, ES ? FI, FR, GB. GR, IE. IT, LU, MC, 
NL, PT, SE). 

Published: 

— With international search report. 

— Before the expiration of the time limit for amending the 
claims and to be republished in the event of receipt of 
amendments. 

(88) Date of publication of the international search report: 

18 January 2001 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations " appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



(54) Title: OBJECT-ORIENTED SYSTEM HAVING ANONYMOUS SCHEDULER DESIGN PATTERN 



-2. 



CONTROL MECHANISM 



-110 



CONTROL 
BOUNDARY 



ANONYMOUS 
SCHEDULER 



120 



-130 



CONTROL POLICY 



HARDWARE 



A COMMAND 
^140 



B:£VENT r 142 



C: COMMIT/REJECT 



Mir 



3 



O 



h RESPONSE 



156 



D. EVENT PENDING 



146 



| EXECUTE EVENT 



H INDICATION 



i 



f: WRITE CONTROL 

Mm 
g: read result 

^152 



(57) Abstract: A method and apparatus are disclosed for scheduling control inputs in an embedded real-time system through anony- 
mous events. An object-oriented design pattern is provided that treats all events anonymously using an abstracted interface. Events 
are said to be anonymous since the details of each event are irrelevant, i.e., only the resource usage of the event is characterized and 
exposed. Deadlines and priorities are assigned to each event, as appropriate for the required quality of service (i.e., urgent events, 
routine events or deferred events). Response times for each event are appropriate to the quality of service associated with the event. 
Guaranteed response time determinism for time-critical events is implemented by re-clocking the event to a periodic time indication, 
such as a video synchronization signal delineating frames in a video feed. Events are validated against system resources at the lime 
the events are submitted to the system to ensure that sufficient resources will exist when the event is to be executed, and if sufficient 
resources will exist, a commitment is provided. 



3NSDOCID: <WO_ 



_0063776A3_L> 



INTERNATIONAL SEARCH REPORT 



Into. onal Application No 

PCT/EP 00/03043 



A. CLASSIFICATION OF .SUBJECT MATTER 

IPC 7 G06F9/54 G06F9/46 



According to International Patent Classification (IPC) or to both national classification and IPC 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 G06F 



Documentation 



searched other than minimum documentation to the extent mat such documents are included in the fields searched 



Elec tronic data base consulted during th e international search (name ot data base and. where practical, search terms used) 

EPO-Internal , IBM-TDB, INSPEC 



a DOCUMENTS CONSIDERED TO BE RELEVANT 



Category * 



Citation of document, with indication, where appropriate, of the relevant passages 



FRANK W. MILLER: "PREDICTIVE DEADLINE 
MULTI-PROCESSING" 

OPERATING SYSTEMS REVIEW (SIGOPS) , US, ACM 
HEADQUARTER. NEW YORK, 
vol . 24, no. 4, 

1 October 1990 (1990-10-01), pages 52-63, 
XP000273169 

page 52, line 1 -page 55, line 6 

EP 0 822 493 A (HEWLETT PACKARD CO) 
4 February 1998 (1998-02-04) 
abstract 

_/__ 



Relevant to daim No. 



1-16 



6,15 



Further documents are listed in the continuation of box C. 



0 



Patent family members are listed in annex. 



° Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E* earlier document but published on or after the international 

filing date 

V document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use. exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

document member of the same patent family 



Date of the actual completion of the international search 



6 November 2000 



Date of mailing of the international search report 

13/11/2000 



Name and mailing address of the ISA 

European Patent Office. P.B. 5818 Patent! aan 2 
NL - 2280 HV Rijswiflc 
Tel. (4O1-70) 340-2040. Tx. 31 651 epo rt. 
Fax: (+31-70) 340-3016 



Authorized officer 



Ecolivet, S. 



Form PCT/1SA/210 (second sheet) (July 1 992) 



page 1 of 2 



BNSDOCID <WO_ 



_0063776A3_I_> 



INTERNATIONAL SEARCH REPORT 



hrtt Jonal Application No 

PCT/EP 00/03043 



C(Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 


Category ° 


, Citation iof document, with indication. where appropriate, of the relevant passages 


Relevant to claim No. 



DOUGLAS C. SCHMIDT: "A C++ WRAPPER FOR 
UNIX I/O MULTIPLEXING THE OBJECT-ORIENTED 
DESIGN AND IMPLEMENTATION OF THE REACTOR" 
C++ REPORT, US, NEW YORK, NY, 
vol. 5, no. 7, 

1 September 1993 (1993-09-01), pages 
32-43, XP000564824 

page 32, right-hand column, line 18 -page 
33, right-hand column, line 2; figure 1 
page 35, left-hand column, line 12 - line 
46 

SE0NGS00 HONG, RICHARD GERBER: "Compiling 

Real-Time Programs into Schedulable Code" 

ACM SIGPLAN NOTICES, US, ASSOCIATION FOR 

COMPUTING MACHINERY, NEW YORK, 

vol. 28, no. 6, 1 June 1993 (1993-06-01), 

pages 166-176, XP000380809 

ISSN: 0362-1340 

page 166, right-hand column, line 8 -page 
167, right-hand column, line 26 

MARGARET M. ADAMS, TIMOTHY E. GRIB: "A 
COMPONENT BASED, EVENT DRIVEN FRAMEWORK 
FOR RAPID PROTOTYPING REAL-TIME AVIONICS 
SYSTEMS" 

PROCEEDINGS OF THE 18TH DIGITAL AVIONICS 
SYSTEMS CONFERENCE, GATEWAY TO THE NEW 
MILLENIUM, 

1999, XP000956376 
Saint Louis, M0, United States of America, 
page 3, left-hand column, line 7 - line 33 
page 6, left-hand column, line 14 -page 8, 
left-hand column, line 6; figure 3 

"HIGH-PERFORMANCE MULTIPLE-PRIORITY EVENT 
QUEUE IN OBJECT ORIENTED ANALYSIS 
IMPLEMENTATION" 

IBM TECHNICAL DISCLOSURE BULLETIN, US, IBM 
CORP. NEW YORK, 
vol. 38, no. 8, 

1 August 1995 (1995-08-01), pages 591-592, 

XP000534644 

ISSN: 0018-8689 



Form PCT/ISA/210 (ooniiraiaticn of second shoot) (July 1992) 
3NSDOCID: <WO 0063776A3_I_> 



1-16 



1-16 



1-16 



page 2 of 2 



INTERNATIONAL SEARCH REPORT 

information on patent family members 



Inte onal Application No 

PCT/EP 00/03043 



Patent document 
cited in search report 



Publication 
date 



Patent family 
members) 



Publication 
date 



EP 0822493 



04-02-1998 



US 
JP 



5828866 A 
10078883 A 



27-10-1998 
24-03-1998 



Form PCT/ISA/210 (patent tamfly anne*) (JJy 1992) 
BNSDOCID: <WO 0063776A3_I_> 



